Skip to content

Conversation

@PieterKas
Copy link
Collaborator

See issue #127

@PieterKas PieterKas requested a review from gffletch September 27, 2024 11:58
@PieterKas PieterKas requested a review from tulshi as a code owner September 27, 2024 11:58
Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token or an OpenID Connect {{OpenIdConnect}} ID token. This workload then performs an OAuth 2.0 Token Exchange {{RFC8693}} to obtain a Txn-Token. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. This context MAY include:

* The external authorization token (e.g., the OAuth access token)
* A reference to the external authorization token (e.g., the OAuth access token). This may inlcude a hash of the authorization token and may including scopes or claims included in the authorization token. To minimise the risk of token theft, It MUST NOT include the unmodified authorization token (see Security Considerations, Section 9.3).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this context of the spec... what needs to be sent to the Txn-Token Service, I believe we want to send the full access token. If not, we should have a longer discussion about what should be sent. My expectation has been that the TTS would validate the access_token for it's authenticity before evaluating the TTS authorization policy to determine whether a TraT should be issued.

@PieterKas PieterKas closed this Sep 27, 2024
@PieterKas PieterKas deleted the PieterKas-patch-2 branch September 27, 2024 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants